【議事録の構成も】議事録後に確認すべきチェック観点28選を解説!
データアナリティクス事業本部@札幌の佐藤です。 今回は今までの私の経験から議事録の目的や、実施時のセルフチェック(レビュー)一覧を記載していきたいと思います。 4月は新入社員の時期でもあり、役割として議事録の作成を依頼されるケースも多いと思いますので何かの参考になれば幸いです。 議事録を読んでみる皆さんに依頼される理由・利点については以前下記に記載しておりますので、併せてご参照いただければと思います。
なぜ議事録が必要であるのか
そもそもなぜ議事録を書く必要があるのでしょうか。 みなさんの議事録に対するイメージは主に下記であると考えています。
- 話している内容を一字一句間違えずにちゃんと書かないといけないので面倒くさい
- そもそも議事録なんて必要?
確かに議事録は面倒ですし、ここに工数を割くのであれば手を動かしたいというのも分かります。 ここではまず、プロジェクト推進において議事録がなぜ必要であるのかを記載します。
プロジェクト推進において議事録が必要ある理由は大きく下記3点であると考えます。
- 内部統制やISO上の文書管理のために証跡を残すため
- 決定事項やToDo事項の自社・クライアント間の合意形成のため
- 会議に参加していないステークホルダーに対し、会議の状況・情報を共有するため
上記から、議事録は、監査・プロジェクト推進において、どのような決定・討議が行われていたのかをステークホルダーに共有・合意形成するために必要であるといえます。
内部統制やISO上の文書管理のために証跡を残すため
主に監査などの要素になります。 議事録は会議やミーティングでの議論内容や決定事項、参加者の意見などを記録した文書となります。 会議の中ではデータの中に存在する個人情報やそれに対する対応・SLAなどの非機能要件に関する内容など、「業務の有効性および効率性」に関する内容を討議するタイミングがあります。 それらの討議内容において、どのような決定を行ったのか議論を追跡しやすくなり、経営判断の透明性が向上します。 また、監査人が企業の内部統制状況を評価する際の重要な資料にもなるため、証跡として残しておく必要があります。
決定事項やToDo事項の自社・クライアント間の合意形成のため
議事録という言葉で思い浮かぶのがこの内容だと思います。 会議の中で決定したことやToDo事項を適切に管理することで、クライアントとの意思疎通・認識齟齬を減少させるためになります。 議事録の内容が問題ないことを相互に合意していくことで、後々何か問題が発生した場合の振り返ることができます。 また何か問題があった際での自衛という点でも議事録が証跡として機能します。
会議に参加していないステークホルダーに対し、会議の状況・情報を共有するため
会議は必ずしも毎回全員参加しているわけでありません。 休暇などで会議に参加していない人だけではなく、普段参加していない関連部署や、クライアント側の上長が状況確認のために確認する場合もあります。 その際に会議がどのような状況であったのかを共有する役割として、議事録が機能します。
議事録の構成について
次に基本的な議事録の構成とそれぞれどのようなことに気を付けるべきかという点について記載します。 また、記載については原則文語調です。 理由は上に書いている通り文書管理の側面や、口語調だとまとまりがないため明確に・簡潔に書く必要があるためです。
議事録の記載 | 対象の読み手 | 意識する点 |
---|---|---|
決定事項 | ・会議参加者 ・ステークホルダー |
・その文章だけで何を示すのか分かるように明確に・簡潔に書く ・文章の解釈が同じになるように書く |
ToDo事項 | ・会議参加者 | ・その文章だけで何を示すのか分かるように明確に・簡潔に書く ・文章の解釈が同じになるように書く ・期限や担当者を明確に記載する |
各討議観点 | ・会議参加者 ・ステークホルダー |
・各ステークホルダーが数週間後~数ヶ月後に読んだ際、どのようなことが討議されたか明確に書く ・議論の前後関係が抜けないように書く ・資料を読む手間を省くため(他資料を確認するホップ回数を減らす)、資料に記載している内容も極力記載する ・途中で発言や方針が変更されるケースがあるため、その場合は結論までの意味が通じるように編集する ・文章が冗長化しないように書く ・文章の解釈が同じになるように書く |
決定事項
会議内で方針確定した内容を記載します。 その文章だけで何を示すのか分かるように明確に・簡潔に書くのが肝心です。 決定事項は討議観点の中でピックアップすることとなりますので、どうしても「下の討議観点を読めばわかるだろ」と考えがちですが、決定事項の文章を読んだだけで何が決まったのかが明確になるように意識することが重要です。 上記にも記載していますが、対象の読み手は会議参加者とステークホルダーになります。 そのため、普段参加していない関連部署や、クライアント側の上長が見た場合にこの観点のみ読んで大体何を話しているのかつかめるという面で明快な記載が必要です。 また、決定事項やToDo事項は次回の定例会議での振り返り事項として改めて話します。 その場合に、文章が抽象的であったり読み手によって複数の解釈ができてしまうと、無用な混乱が生じてしまう可能性があります。
ToDo事項
会議の中でのToDo事項を記載します。 こちらも決定事項と同様に明確に・簡潔に書くのが肝心です。 読み手をしては、普段参加していない関連部署や、クライアント側の上長は含まず、あくまで普段会議に参加している人という形になると思います。
決定事項とToDo事項何が厳密に違う?
決定事項とToDo事項何が厳密に違うんだ?という点も議事録を作成されている方であると思います。私も議事録を書き始めたころは強く感じていました。 勘所としては下記かと思います。
分類 | 勘所 |
---|---|
決定事項 | 大きなタスク単位でなにかが決まった・今後こういうことやりましょうというざっくりした方針の決定(タスクが詳細化されていない・これから決めていくもの) |
ToDo事項 | 直近で誰かが何かをしなければいけないことが明確(タスクが詳細化されている) |
各討議観点
各討議議題に対して、討議した内容を記載することになります。 各討議観点で重要な要素としては、基本的にエンジニアの議事録は発言録を取るものではないという点になります。 一般的に議事録と考えると、発言内容を流れそのままで一言一句間違えずに書いていくというものを想像すると思いますが、現実にはそのケースでの議事録は多くありません。 (私の経験上、執行役員クラスの方との会議の時のみでした) どちらかというと、ひとつの討議テーマについて文章の解釈が同じになるよう、順番を整理しながらも、明確に書いていくということのほうが多いです。 会議中によくあるのが、途中で発言や方針が翻るケースだと思いますが、その場合それまでの話は不要となりますので、削ってしまっても問題ないと思います。 (話が途中で翻ったことを後で知りたい人はいないためです。) また、日本語での会話は間の言葉が抜け落ちています。 その言葉を前後の内容から補記し、文章の解釈が人によってまちまちにならないようにするという点が重要となります。 具体的にどのようにすべきかは下記をご参照ください。
各討議観点の重要なところは、ひとつの討議テーマの意味が通じ、解釈が一致するように編集していくことが重要かなと考えています。
なぜ解釈を一致させるような記載が必要なのか
議事録の記載内容を改めて確認する場合はいつになるのかと考えたとき、経験上何かしらの問題が起きたときになります。 そのタイミングは討議した内容から数ヶ月後、もしかしたら1年後かもしれません。 その時に解釈が人によってまちまちの場合、何を話したのかが明瞭になりませんので、責任の所在という点において非常にあいまいになりがちです。 何を話して何を合意したのかは明確にしておくべきかと考えます。
議事録を書く際の鉄則
今までの内容含めた、議事録を書く際の鉄則は下記になります。
- エンジニアの議事は発言録ではない。会話内容をある程度のテーマのまとまりでグルーピング・整理して書く
- 議事録は文語調で書く
- あとあと読んだ際に文脈が不明確にならないように書く
- 読み手によって解釈が異なるようなことが発生しないように書く
- 会議参加者・プロジェクトに関連する人たちが読み手になった際に伝わるように書く
- 議事録は会議の実施時間以上使わない
議事録を書いたらどうするべきか
当然ですがクライアントにご連絡します。 クライアントにご連絡するタイミングとしては会議当日が望ましいです。 議事録は明確に鮮度が存在しているものになります。 毎週定例会議を実施しているとして、前週の定例会議の議事録が今週の定例会議よりも後になった場合、鮮度としては古くなりますので、議事録の価値が下がります。 また、ToDo事項や決定事項をクライアントと共有するタイミングを逸していまうため、コンセンサスの観点からもよくありません。 ご連絡した議事録は、当然クライアント側の確認をもっての完了となる点も気を付けるべき点となります。 提出することが目的ではなく、議事に対し両者問題ないという合意をもってクローズされるべきです。 ただ、クライアント側もお忙しい場合もありますので、ToDo事項や決定事項を次回の会議で話す前提とし、「違和感があればご連絡ください」というニュアンスでお伝えし、完了するのが良いかと考えます。
セルフチェックシート・レビューシート
最後に議事録実施後のセルフチェックや、レビュー一覧を記載します。 実際のチェックで有用な場合にご利用ください。
# | チェック観点 | 補足 |
---|---|---|
1 | 話し言葉のままのものがないか | 議事録は口語調ではなく文語調。軽い印象を与えないようにする。 だと思う→見込み |
2 | 固有名称は正確に書いているか | 資料名、機能名、部署名など略称・通称で呼ばれるケースがあるため、正確に書きなおす |
3 | 主語目的語を省略していないか | 5W1Hを正確に記載しないと文脈が不明確で解釈が分かれる原因となる。 前後の流れを読めばわかると考えずに正しく書く 会議で主語がなかった場合は必ず議事録で補記する |
4 | 「多くない」などあいまいな打消をしていないか | 抽象的な表現のため極力具体的に表記にする(多いのか少ないのか分からない) |
5 | 一般的ではない英語利用をしていないか | 何言っている分からない問題を指す。 IT業界やクライアント内で一般的ものは採用しない |
6 | 省略に近い英語を避けているか | サマる、ジョインするなど、比較的口語調なものは文語調で書く |
7 | 矛盾する熟語・重複する熟語を組み合わせていないか | 「頭痛が痛い」や「まず最初に」などの二重表現や矛盾した表現を使わない |
8 | 他者への配慮を考慮しているか | 例えクライアント側が言ったとしても他人を卑下する言葉を使用せず、該当部削除や、文言変更を行う |
9 | 「~については要検討」というワードを議事録で多用していないか | 多用しがち表現。多用する場合は別の言葉に言い換える |
10 | 並列に語る場合は「・」を用いているか | 読点は日本語としては息を吸う動作のため、並列の場合は読点を用いらない |
11 | 抽象的な表現は避けているか | 「~なイメージ」等の抽象的な表現は割ける。極力断言するように書く |
12 | 年月に該当する文言は正確に記載されているか | 本日や今週・来週は読み手によって異なるため、正確な日時を記載する |
13 | 時期やタイミングは正確に記載されているか | 重要な事項の時期が不明確になってしまわないように正確な日時を記載する |
14 | 「~ので」という表現を行っていないか | よくやりがちな口語 |
15 | 「お」と「ご」の使い分けが正確にされているか・過剰ではないか | 「お名前」「ご意見」など。意味もなく付けていないか |
16 | 会議中での明らかな言い間違いを修正しているか | 一般的な配慮 |
17 | 特に議論がなくても「承知した」「了解した」を書いているか | 相手が無言でも何も言わない=了解したことになるため |
18 | 会議で話していることが自分にとって理解したうえで書いているのか | 議事録はプロジェクトを理解するためのキャッチアップ手段として利用するべき |
19 | 括弧が半角全角が混ざっていないか | どちらかに統一すること |
20 | 1文に同じ用語を連続で使用していないか | 1文で同じ用語は冗長のため省略、あるいは別の会話として改行するなど考慮する |
21 | 1文が長くなっていないか | 1文が長いと可読性が下がるため考慮する。 結論を先に記載、補記として「具体的には」・「下記」で調整する |
22 | 「あの」「その」などの指示語の多様していないか | 正式名称を正しく書くこと |
23 | 会話前後のつながりが悪くなっていないか | 唐突なワードは後々読んで違和感を感じてしまう。 人によって解釈が異なってしまう原因となる |
24 | 議題の分類分けが正しく行われているか | ひとつの討議議題の中で複数のテーマの話題が入っていると読みにくいため、分割・調整するように構成する |
25 | 日付のフォーマットの統一しているか | yyyy/mm/ddとyyyy年mm月dd日などフォーマットがまちまちにならないようにする |
26 | 不自然なインデントは避けているか | (Markdown記法の場合)インデントを入れる書き方にしない。立場に上下があるようにとられるため、議題ベースで統一のインデントにすること 例) - XXXとしたいが問題ないか - 問題ない ↓ - XXX - XXXはYYYYとしたい問題ないか - 問題ない |
27 | 感嘆符や疑問符(!や?)を文章内に入れないか | 公的文書では用いらない表現のため |
28 | 「ら」抜き言葉が存在していないか | 「見れる」などの誤用は避ける |
最後に
私も議事録は苦手で、新入社員の時に練習をしていました。 この内容が誰かの参考になれば幸いです。